home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 772 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.7 KB
  1. Path: solon.com!not-for-mail
  2. From: spc@gate.net (Sean 'Captain Napalm' Conner)
  3. Newsgroups: comp.std.c,comp.lang.c.moderated
  4. Subject: Re: printf() format extensions - looking for beta testers...
  5. Date: 20 Apr 1996 14:17:40 -0500
  6. Organization: CyberGate, Inc.
  7. Sender: clc@solutions.solon.com
  8. Approved: clc@solutions.solon.com
  9. Message-ID: <4lbd8k$m2t@solutions.solon.com>
  10. References: <4ksk72$rm6@solutions.solon.com> <4l33qn$7rv@solutions.solon.com> <4l3kg4$avi@solutions.solon.com>
  11. NNTP-Posting-Host: solutions.solon.com
  12.  
  13. In article <4l3kg4$avi@solutions.solon.com> seebs@solon.com writes:
  14.  >In article <4l33qn$7rv@solutions.solon.com>,
  15.  >Sean 'Captain Napalm' Conner <spc@gate.net> wrote:
  16.  >>In article <4ksk72$rm6@solutions.solon.com> seebs@solon.com writes:
  17.  >> >In article <4kr74a$k8o@solutions.solon.com>,
  18.  >> >Whatever you want; it's just that if you change %#, you change the behavior
  19.  >> >of existing legal programs.
  20.  >
  21.  >>  Existing legal programs using your printf()?
  22.  >
  23.  >No... I mean that, if this extension or change were adopted, the goal is that
  24.  >all currently defined programs continue to be defined to do the same thing,
  25.  >and the changes will affect only code using new features.
  26.  >
  27.  >Given that, though, if (using this extension) you were to change the behavior
  28.  >of the # character in a printf format, previously written code would change in
  29.  >behavior.  This is a feature, sort of, but is one to be wary of.
  30.  >
  31.   And one I'm wary of.  Again, if I use pre-written code that uses a character
  32. for a new format that my code wants to use, something isn't going to work
  33. properly (<sarcasm> and given how well Unix code is well documented
  34. </sarcasm>).
  35.  
  36.   As a defence, at least have a compile time option (or run time option) to
  37. flag options that are redefined, to at least warn the programmer "Thar be
  38. possible bugs ahead, Arrrrrrrrg!  You have been warned, me mateys!"
  39.  
  40.  >>  Again, existing code you wrote?  Gee, just like make requiring tabs (and
  41.  >>only tabs).  Can't fix it, because too many make files would "break" (sorry,
  42.  >>my anti-Unix bias is showing 8-)
  43.  >
  44.  >I'm not sure how a makefile using tabs would break on a make allowing
  45.  >tabs-or-spaces, but that's atopical; feel free to email me with an example.
  46.  >
  47.   It's not THAT case that breaks, it's the case where using a space in a make
  48. that only wants tabs that breaks.  And most make's I've seen are of that
  49. variety (in fact, I'm having to use one right now.  Bug pain in the butt, with
  50. no other options.  Arrrrrrg!  Which means I'm limited to the editors I use to
  51. edit the makefile (and this particular lossage isn't even under Unix)).
  52.  
  53.  >>  But you still have the problem of overloading (what if I wanted to use %<
  54.  >>for something?).
  55.  >
  56.  >Then you'd change it.  My current design allows you to make %d always print a
  57.  >1.  You are not required to use the standard set of flags.  (This is a quality
  58.  >of programmer issue.)    The idea would be to offer some new format flags,
  59.  >and then also provide a generic way to add new ones, or replace old ones.
  60.  >
  61.  >I'm hoping to get this or a similar proposal added, because it would make my
  62.  >lifie immensely easier.
  63.  
  64.   And I'm afraid that it'll make my life a living hell (sorry, but I have
  65. enough problems working with existing poorly written C code (that I have to
  66. use or get to work) to fully endorse such a construct.    Nothing personal).
  67.  
  68.  >I'm still looking at similar proposals.  I have
  69.  >decided that I'm probably going to have to choose a different way to pass data
  70.  >around, though.
  71.  >
  72.   Does it HAVE to be printf()?    Can't you create formatp() and use that?  Or
  73. are you wanting to change some of the default behaviors of printf() so you (or
  74. someone else) don't(doesn't) have to change much code?
  75.  
  76.   -spc (As if there wasn't problems with *printf() already ... )
  77.